REMARKS 

The rejections presented in the Office Action dated July 1, 2004 have been 
considered. New claims 16-25 are added, and claims 1-25 remain pending in the application. 
Reconsideration and allowance of the application are respectfully requested. 

The Office Action does not establish that claims 1-15 are anticipated under 35 USC 
§ 102(e) by U.S. Patent No. 6,212,640 to Abdelnur et al (hereinafter "Abdelnur"). The 
rejection is respectfully traversed because the Office Action fails to show that all the 
limitations of the claims are taught by Abdelnur. 

For example, claim 1 includes limitations of the file interface arrangement including a 
memory configured with program code that implements at least one non-standard extension 
to the NFS client protocol, and the Office Action does not show that Abdelnur teaches these 
limitations. The Office Action cites Abdelnur 's figure 7, #715; however, there is no apparent 
indication, either in the figure or the accompanying text, that there is any extension to the 
NFS client protocol. Therefore, the Office Action fails to show that Abdelnur anticipates 
claim 1. If the rejection is maintained, a citation to teachings of Abdelnur for this limitation 
is respectfully requested. 

The Office Action fails to show that Abdelnur anticipates claim 2 which includes 
limitations of an interceptor module coupled to the operating system and to the system bus, 
the interceptor module configured and arranged to intercept NFS-client calls from the NFS 
client application and send NFS-client calls to the processor arrangement via the system bus. 
Abdelnur appears to have no need for an interceptor module because an Abdelnur client 
makes an NFS API call, which is code executing on the processor. Thus, there is no need to 
"intercept" and "send" any call to a processor arrangement since Abdelnur's processor is 
already executing the API call. 

Claim 3 includes further limitations of intercepting messages from a stream, and the 
Office Action fails to show a suggestion of these limitations. Those skilled in the art will 
recognize that a stream is "an abstraction referring to any flow of data from a source (or 
sender, producer) to a single sink (or receiver, consumer). A stream usually flows through a 
channel of some kind, as opposed to packets which may be addressed and routed 
independently, possibly to multiple recipients. Streams usually require some mechanism for 
establishing a channel or a "connection" between the sender and receiver." (see the "Free On- 
Line Dictionary of Computing (FOLDOC) at http://foldoc.doc.ic.ac.uk/foldoc/index.html). 
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In contrast, the cited section of Abdelnur teaches a client making API calls for NFS file 
access (col. 6, 11. 24-32). There is no apparent indication that Abdelnur in any way uses 
streams. Since the claim clearly sets forth an OS message stream and an interceptor module 
that intercepts NFS messages from the message stream, and Abdlenur does not suggest 
streams, the Office Action does not show the limitations of claim 3. 

As to claims 4, 6, and 7, these claims include limitations that indicate different types 
of extensions to the NFS client protocol. Abdelnur's figure 2 shows an NFS client coupled to 
an NFS server, and figure 7 simply shows a computer coupled to a network. Furthermore, the 
accompanying text does not appear to suggest any non-standard extensions to the NFS client 
protocol. As with claim 1, the Office Action does not show that Abdelnur shows any 
extension to the NFS client protocol. Thus, there is also no showing of those particularly 
identified extensions. 

Claim 5 includes limitations of the interceptor module being configured and arranged 
to intercept packets from the RPC layer of the operating system. In contrast, Abdelnur 
simply teaches that RPC calls are made by an NFS client. There is no apparent suggestion 
that Abdelnur's NFS RPC requests are in any way intercepted so that they handled differently 
from non-NFS RPC requests. Thus, claim 5 is not shown to be anticipated by Abdelnur. 

Claim 8 is a method claim and includes some limitations similar to those in claims 1 
and 2. Thus, claim 8 is not anticipated for at least the reasons set forth above for claims 1 and 
2. In addition, claim 8 includes limitations of sending non-NFS RPCs to the second network 
interface card; and performing non-NFS RPC protocol processing on the second network 
interface card. It is respectfully submitted that Abdelnur does not appear to show or suggest a 
second interface card, nor is any particular element of Abdelnur cited as teaching this 
limitation. Thus, the Office Action does not show that Abdelnur anticipates claim 8. 

The process limitations of claims 9-14, which depend from claim 8, are similar to the 
limitations of claims 1-7. Therefore, the Office Action does not show that claims 9-14 are 
anticipated for the reasons set forth above for claim 8 and for claims 1-7. 

Claim 15 is an apparatus claim. For limitations in claim 15 that are similar to those in 
claim 1 , the Office Action does not show that Abdelnur teaches the limitations of claim 1 5. 
Furthermore, claim 1 5 is in means-plus-function format, and the Office Action fails to recite 
structure from the current specification thought to be taught by elements of Nguyen. Thus, if 
the rejection is maintained, an explanation of the relied upon structures and corresponding 
elements is respectfully requested. 
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Withdrawal of the rejection and reconsideration of the claims are respectfully 
requested in view of the remarks set forth above. 

Respectfully submitted, 



CRAWFORD MAUNU PLLC 
1270 Northland Drive, Suite 390 
Saint Paul, MN 55120 
(651)686-6633 
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By: _ 

Name: LeRoy D. Maunu 
Reg. No.: 35,274 
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